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® Verfahren zurn Kornprimiern von dynamischen Webseiten und eine Date nverarbeitungseinricht Ling zur 
Durchfuhrung des Verfahrens 

® Zum Komprimieren von dynamischen Webseiten wird 
vorgeschlagen, die dynamischen Webseiten auf statische 
Blocks zu untersuchen und nur die statischen Blocks, 
nicht aber in jedem Fall auch die dynamischen Blocke zu 
komprimieren, es sei denn, die Belastung der CPU des 
Webservers erlaubt dies. Dis statischen Blocke werden in 
komprimierter Form abgespeichert, so dalS beim emeu- 
ten Abrufen keine erneute Kompression, sondern ledig- 
lich ein Ersetzen der unkomprimierten durch die kompri- 
mierten statischen Blocke erfolgen mu(S. 
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Beschreibung 

[0001] Die Erfindung betrifft ein Verfahren zum Komprimieren von dynamischen Webseiten sowie eine Datenverar- 
beitungseinrichtung zur Durchfunrung des Verfahrens. 
5 [0002] Dynamische Webseiten bestehen aus Inhalten, die zum Tfeil standig aktualisiert bzw. auf einen Nutzer angepaBt 
werden. Eine standige Aktualisierung erfolgt beispielsweise bei Webseiten, welche Borsenkurse wiedergeben. Eine auf 
den Nutzer angepaBte Anderung erfolgt beispielsweise bei Webseiten im ]>Commerce-Bereich. 

[0003] Derartige dynamische Webseiten konnen als Template also als Schablonen oder lediglich als Beschreibung von 
Aufbau und Inhalt der Webseite auf dem Webserver abgelegt sein, 

10 [0004] 1st eine Webseite als Template abgelegt, ist dessen Struktur vorgegeben. Eine solche Webseite kann daher ent- 
sprechend ihres Inhalts in statische und dynamische Blocke unterteilt werden. Der Inhalt der dynamischen Blocke ist 
durch eine Abfolge von Befehlen in einer Prograrnmier-, eine Skript- oder auch einer Kommandosprache beschrieben, 
[0005] Bei einem Abruf der Seite durch einen Nutzer ersetzt der Application-Server die Beschreibung durch die aktu- 
ellen Inhalte, Aussehen und Aufbau bleiben bei einer aus einem Template generierten Webseite unverandert, wie dies in 

15 Fig. 1 gezeigt ist. 

[0006] Statische Blocke enthalten Inhalte, die nie oder in sehr groBen Zeitabstanden generiert werden. Diese Blocke 
sind oft in HTML geschrieben. 

[0007] Die Inhalte dynamischer Blocke werden in kurzen Zeitabstanden, z, B, bei jedem Abruf der Webseite, generiert. 
Die Inhalte sind zunachst nur beschrieben. Erst beim Generieren wird diese Beschreibung dann durch Daten ersetzt. 
20 [0008] Die Beschreibung kann durch eine Programmier-, eine Skript- oder auch eine Kommandosprache erfolgen. Ge- 
wohnlich werden Skriptsprachen verwendet, da diese sich gut in HTML integrieren lassen. Beispiele fur Skriptsprachen 
sind: 

- PHP (abgeleitet aus Hypertext Preprocessor) als eine offene serverseitige Skriptsprache, die jeder frei nutzen und 
25 andern kann oder 

- JSP (Java Server Pages) 

[0009] Der Nutzer ruft mit dem Eingeben und Bestatigen einer URL-Adresse im Browser eine %bseite auf. Das be- 
deutet, der Browser sendet an den Webserver ein Request (Anfrage), Dieser Request enthalt neben der URL der ge- 
30 wunschten Webseite eine Fulle von Informationen iiber die Fahigkeiten des Browsers, z, B. iiber die unterstiitzten Kom- 
pressions verfahren, MIME- Ty pen oder den Browser Typ. Der Webserver wertet den Request aus und versucht, die zu 
ubertragenen Daten an den Browser anzupassen. 

[0010] Statische Webseiten sind in derRegel auf dem Webserver in komprimierter Form (GZip- und Compress-For- 
mat) abgelegt. GZip und Compress sind die gangigen Kompressions verfahren fur statische "v\febseiten. Entsprechend den 

35 Fahigkeiten des Browsers wird die Webseite im GZip- oder Compress-Format ubertragen. 

[0011] Unterstiitzt der Browser kein Kompressionsverfahren, iibertragt der Webserver die Webseite unkomprimiert. 
[0012] Die Anfrage zu einer dynamischen Webseite reicht der Webserver zum Application-Server weiter, Dieser iiber- 
nimmt das Generieren der dynamische Blocke. Das heiBt, er ersetzt die beschriebenen dynamischen Blocke durch deren 
Inhalt. Die statischen Blocke der Webseite werden unkomprimiert eingefiigt. Der Application-Server iibergibt die voll- 

40 standige dynamische Webseite dem Webserver. Dort kann eine Komprimierung erfolgen. Am Ende sendet der Webserver 
die Webseite zum Browser, wie dies Fig, 2 zeigt, 

[0013] Der Umfang und die Bedeutung dynamischer Webseiten im Internet nimmt aufgrund der viefMltigen Einsatz- 
moglichkeiten standig zu. Beispiele sind dynamische Webseiten, die aktuelle Aktienwerte bereitstellen oder bei denen 
Wetterinformationen abgerufen werden konnen. 
45 [0014] Dynamische Webseiten stellen aber an die Webserver bedingt durch ihre Eigenschaften groBere Anforderun- 
gen. Die Schwierigkeit besteht im Bereitstellen komprimierter dynamischer Webseiten unter Beriicksichtigung der Effi- 
zienz des Webservers. 

[0015] Zwei wichtige GroBen fur die Effizienz eines Webservers sind die Verkehrslast und die CFU-Belastung. Ziel ist, 
daB beide GroBen in einem ausgewogenen Verhaltnis zueinander stehen und das stets eine Reserve fur auftretende Spit- 
50 zen verfugbar ist. 

[0016] Das Problem bei dynamischen Webseiten ist, daB sie sich nicht wie statische Webseiten vorkomprimieren und 
auf dem Webserver ablegen lassen. Damit konnen sie auf die zwei GroBen entscheidenden EinfluB haben. Folgende Si- 
tuationen sind moglich: 

Die dynamischen Webseiten werden nicht komprimiert und erhohen damit aufgrund des groBeren Datenumnmgs massiv 
55 die Verkehrslast des Webservers. 

[0017] Die dynamischen Webseiten werden erst unmittelbar nach deren Generierung mit einem bestehendem Verfah- 
ren komprimiert. Der Nachteil ist eine hohe CFU-Belastung des Webservers, 
[0018] Das Diagramm gemaB Pig, 3 verdeutlicht die Problematik: 

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Komprimieren von dynamischen Webseiten sowie eine 
60 Daten verarbeitungsvorrichtung fur diesen Zweck vorzuschlagen, mittels derer in einfacher Vfeise eine Kompression bei 
verbesserter Ausnutzung des Ressourcenverbrauchs sichergestellt wird. 

[0019] Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Datenverarbeitungseinrichtung nach An- 
spruch 21 gelost. 

[0020] In der nachfolgenden Beschreibung wird das erfindungsgemaBe Verfahren als "SSC" (Server Side Compres- 
65 sion) bezeichnet. 

[0021] Ein wesentlicher Punkt der Erfindung liegt darin, daB nicht "blind" komprimiert wird, sondem daB nur diejeni- 
gen Daten komprimiert werden, welche einen wesentlichen Anteil der gesamten zu libertragenden Datenmenge bilden 
und die andererseits mit verringertem Aufwand komprimierbar sind. Die statischen Daten werden namlich nur bei einem 
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"Neuaufbau" einer Webseite geandert, bleiben also iiber lange Zeit unverandert erhalten. Die konnen darum in kompri- 
mierter Form abgespeichcrt und immer wieder vcrwendet werden. 

[0022] Die Erfindung wird nachfblgend unter Bezugnahme auf die Abbidungen naher beschrieben. Hierbei zeigen: 
[0023] Fig, 1 einen Seitenabrufvorgang; 

[0024] Fig, 2 einen herkomrnlichen Aufbau der Hardware; 5 

[0025] Fig. 3 ein Diagramm zur Hardwarebelastung bei herkomrnlichen Techniken; 

[0026] Fig. 4 ein Diagramm zur Hardwarebelastung beim erfindungsgemaBen Verfahren; 

[0027] Fig, 5 einen herkomrnlichen DalenfluB; 

[0028] Fig, 6 einen Datenflufl beim erflndungsgemaflen Verfahren; 

[0029] Fig. 7 einzelne Schritte beim Entstehen eines SSC-Dokuments; 10 
[0030] Fig. 8 einen Tag-Einfugevorgang; 
[0031] Fig, 9 den Aufbau einer Block-Datei; 
[0032] Fig, 10 einen 1, Kompressionsvorgang; 
[0033] Fig, 11 einen 2. Kompressionsvorgang; 

[0034] Fig. 12 ein SSC-Dokument und 15 
[0035] Fig. 13 einen schematischen Aufbau einer Datenverarbeinmgseinrichtung gemaB der Erfindung. 
[0036] Eine Analyse dynamischer Webseiten in bezug auf die Zusammensetzung der Daten erbrachte folgendes Ergeb- 
nis: Der Antcil dynamischer Daten im Verhaltnis zu den statischen ist wesentlich geringer, Werden von einer dynami- 
schen Webseite also lediglich die statischen Daten komprimiert und die dynamischen unkomprimiert ubertragen, ist 
keine wesentliche Verringerung des Komprimierungsfaktors gegeniiber einer Komprimierung der kompletten Webseite 20 
zu erwarten. 

[0037] Diesen Effekt nutzt SSC, Bei dem Verfahren wird auf eine bessere Komprimierung zugunsten einer geringeren 
CPU-Belastung verzichtet. Es ist ein Kompromiss zwischen den beiden oben beschriebenen Moglichkeiten. Das Ergeb- 
nis veranschaulicht das Diagramm gemaB Fig. 4: 

Das Verhaltnis von Verkehrslast und CFU-Belastung ist nahezu ausgeglichen, der Ressourcenverbrauch des Webservers 25 
ist gering, 

[0038] Insbesondere wird also mit der Erfindung ein Verfahren zum Komprimieren von dynamischen Webseiten auf- 
gezeigt, insbesondere zum Komprimieren von Webseiten, die mindestens einen statischen Block und mindestens einen 
dynamischen, insbesondere durch Abruf von einem Nutzer veranderlichen Block aufweisen, die auf einem Observer 
und einem Application-Server vorgehalten oder generiert werden. Beim erflndungsgemaBen ^ferfahren werden nun fol- 30 
gende Schritte vorgenommen: 

Es wird ein Daten satz aufgenommen, der mindestens einen statischen und einen dynamischen Block urnfaBt. 

[0039] Es wird jeweils eine Identitat aller im Datensatz vorhandenen statischen Blocke, also ein "Fingerprint" festge- 

stellt. 

[0040] Es wird festgestellt, ob statische Blocke mit derselben Identitat (mit demselben Fingerprint) in einem Block- 35 
speicher schon als komprimierte Blocke gespeichert sind. Wenn dies der Fall ist, so wird der im Datensatz vorhandene 
statische Block durch den entsprechenden kompriroierten Block ersetzt. Wenn dies nicht der Fall ist, so wird der statische 
Block komprimiert und im Blockspeicher als komprimierter Block abgelegt Der komprimierte Block ersetzt dann wie- 
der den im Datensatz vorhandenen statischen Block. 

[0041] Abschliefiend wird ein Sendedatensatz abgesendet, bei welchem die statischen Blocke durch komprimierte 40 
Blocke ersetzt sind, wobei der Sendedatensatz selbstverstandlich auch die dynamischen Blocke enthalt. 
[0042] Vorzugsweise wird die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen Kennung 
festgestellt. Diese Kennung soil so sein, daJ3 eine Verwechslung mit anderen statischen Blocken (Blocken anderen In- 
halts) unwahrscheinlich ist. Die aus der Identitat gewonnene Kennung wird jedem komprimierten Block zugehorig im 
Blockspeicher gespeichert und beim Feststellen der Identitat zum ^rgleich mit den Identitaten der statischen Blocke im 45 
Datensatz verwendet. Es werden also nicht die statischen Blocke selbst miteinander verglichen sondem - was eine we- 
sentliche Verringerung des Aufwandes bedeutet - lediglich ihre Kennungen. Es kann als Kennung eine Priifsumme iiber 
den statischen Block, insbesondere eine CRC-32-Summe verwendet werden. 

[0043] CRC-32 (Cyclic Redundancy Check mit 32-Bit-Prufsumme) ist ein gebrauchliches mathematisches \erfahren 
zum Ermitteln einer Priitsumme. Mit Hilfe dieser Pruf summe konnen Identitatsprufungen durchgefuhrt oder wie bei SSC 50 
Datenmengen verglichen werden. Der Vorteil dieses Verfahrens ist, dai3 eine geringe Abweichung bei den Daten eine 
groBe Anderung der Prufsumme bewirkt und damit auch kleinste Fehler nicht iibersehen werden konnen. 
[0044] Die Verkehrslast bestimmt die Datenmenge, die innerhalb eines Zeitintervalls vom Webserver abgefordert wird. 
Sie ist abhangig von der Anzahl der Requests (Anfragen zu Webseiten, die auf dem Webserver abgelegt sind) und von der 
Datenmenge, die als Antwort pro Request zum Client iibertragen wird. Wahrend eine hohe Anzahl an Requests er- 55 
wunscht ist, versucht man die zu iibertragende Datenmenge durch Kompressions verfahren moglichst gering zu halten, 
um damit die Ressourcen des Webserver nicht unnotig zu blockieren, 
[0045] Vorzugsweise umfaOt die Kennung die Lange des statischen Blocks. 

[0046] Zusatzlich zu jedem komprimierten Block wird vorzugsweise der dazu gehorige statische Block abgespeichert. 
Bei Bedarf steht dieser somit zur Verfugung. 60 
[0047] Die Daten werden vorzugsweise nach dem (an sich bekannten) DEFLATE- Verfahren komprimiert, Durch die 
Verwendung dieses bekannten Verfahrens ist eine Dekompression bei einem Empfanger bzw. Nutzer leicht moglich, 
[0048] Die dynamischen Blocke kann man im wesentlichen unverandert, insbesondere unkomprimiert im Datensatz 
senden. Wenn nun aber der Server zum Zeitpunkt, zu welchem die Webseite abgerufen wird, nur wenig ausgelastet ist, so 
kann man die dynamischen Blocke (oder einige der dynamischen Blocke) ebenfalls komprimieren und als komprimierte 65 
dynarnische Blocke in den Sendedatensatz einfiigen. Es erfolgt also eine Komprimierung "on fly". Dadurch werden die 
vorhandenen Ressourcen optimal genutzt, eine Uberlastung des Servers jedoch vermieden. 

[0049] Weiterhin besteht die Moglichkeit, dynarnische Blocke nicht nur unkomprimiert oder "on the fly" komprimiert 
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(je nach Serverlast) auszuliefern, sondern dynamische Blocke, welche durch ein bestirnmtes Merkmal (z. B. ihrer GroBe) 
herausstechen, vorkomprimiert (wie die statischen Blocke) abzulegen. Dies wird im Fall des Merkmales der GroBe bei 
Uberschreiten eines Schwellwerts erfolgen. 

[0050] Weiterhin ist sinnvoll, fur jede Kompression eines Blockes eine erforderliche MindestgroBe (untere Schranke) 
5 zu definieren, welche uberschritten werden muB, damit eine Kompression iiberhaupt durchgefuhrt wird. So konnen z. B. 
beim Server einer Zeitung Arlikel aus einer Datenbank heraus generiert werden, die also dynamisch sind. Andererseits 
andert sich ein Artikel im Regelfall nicht mehr. Es macht also in diesem Fall Sinn, ihn hinsichtlich Kompression wie ei- 
nen statischen Block zu behandeln. 

[0051] Jedem letzten Block eines Datensatzes wird ein Endhlock zur Bezeichnung des Endes des Datensatzes hinzu- 
10 gefugt, was die Handhabbarkeit der Datensatze erleichtert. 

[0052] Jedem Block des Datensatzes wind ein Tag zur Kennzeichnung als dynamischer oder als statischer Block hin- 
zugefugt, wobei diese Hinzufugung vorzugsweise an erster S telle des Blocks erfolgt Die Tags werden vorzugsweise als 
HTML-Kommentar ausgebildet, 

[0053] Vorzugsweise werden die Tags von einem Parser eingefugt, der auf dem Apphcation- Server lauft und auf abge- 
15 legte Templates zugreift, die er Block fur Block analysiert und denen er die Tags hinzufiigt. Die mit den Tags markierte 
noch urikomprimierte Webseite wird einem Pre-Compressor zugefuhrt, der entsprechend markierte Blocke komprimiert, 
die zusammen mit unkomprimierten Blocken dann einem Post-Compressor ubergeben werden. Der Post-Compressor er- 
stellt schritthaltend zur Datenbearbeitung durch den Pre-Compressor, also verzahnt mit diesem arbeitend ein neues Do- 
kument und zwar vorzugsweise nach dem GZip-Format. Nach Bildung eines GZip-Headers reiht der Post-Compressor 
20 die vom Pre-Compressor iibergebenen Blocke unmittelbar mit der Ubergabe in das neue Dokument ein, was eine hoch- 
effektive und schnelle Bearbeitung ermoglicht, 

[0054] Der Post-Compressor kennzeichnet unkomprimierte Blocke durch einen Header und zwar vorzugsweise einen 
solchen nach dem DEFLATE-Format. 

[0055] Der Post-Compressor erstellt einen zusatzlichen END-Block und fugt diesen zur Kennzeichnung eines Endes 
25 der Datenblocke dem neuen Dokument hinzu, Weiterhin errechnet der Post-Compressor eine Checksumme, insbeson- 
dere eine CR-3 2-Priif summe und die GroBe des urikomprimierten neuen Dokuments fur einen Trailer, der ebenfalls hin- 
zugefiigt bzw. gesendet wird. 

[0056] Die erfindungsgemaBe Datenverarbeitungseinrichtung zum Komprimieren von dynamischen Webseiten, insbe- 
sondere zum Komprimieren von dynamischen Webseiten, die mindestens einen statischen Block und mindestens einen, 
30 insbesondere durch Abruf von einem Nutzer veranderlichen dynamischen Block aufweisen, urnfaBt einen "Observer und 
einen Application-Server. Es ist ein Precompressor vorgesehen, der so ausgebildet ist, daB bei Aufforderung durch den 
Webserver an den Application-Server, eine dynamische Webseite zu generieren, der Precompressor eine noch unkompri- 
mierte Website in folgenden Schritten bearbeitet: 

Es wird festgestellt, oh statische Blocke mit derselben Identitat (mit demselben Fingerprint) in einem Blockspeicher 
35 schon als komprimierte Blocke gespeichert sind. Wenn dies der Fall ist, so wird der im Datensatz vorhandene statische 
Block durch den entsprechenden komprimierten Block ersetzt. Wenn dies nicht der Fall ist, so wird der statische Block 
komprimiert und im Blockspeicher als komprimierter Block abgelegt, Der komprimierte Block ersetzt dann wieder den 
im Datensatz vorhandenen statischen Block, 

[0057] Abschliefiend wird ein Sendedatensatz abgesendet, bei welchem die statischen Blocke durch komprimierte 
40 Blocke ersetzt sind, wobei der Sendedatensatz selbstverstandlich auch die dynamischen Blocke enthalt. 

[0058] Vorzugsweise wird die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen Kennung 
festgestellt. Diese Kennung soli so sein, daB eine Verwechslung mit anderen statischen Blocken (Blocken anderen In- 
halts) unwahrscheinlich ist. Die aus der Identitat gewonnene Kennung wird jedem komprimierten Block zugehorig im 
Blockspeicher gespeichert und beim Feststellen der Identitat zum Vergleich mit den Identitaten der statischen Blocke im 
45 Datensatz verwendet. Es werden also nicht die statischen Blocke selbst miteinander verglichen sondem - was eine we- 
senthche Verringerung des Aufwandes bedeutet - lediglich ihre Kennungen, Vorzugsweise wird als Kennung eine Priif- 
summe iiber den statischen Block, insbesondere eine CRC-32-Summe verwendet. 

[0059] Fur SSC werden drei SSC-Komponenten in die bestehende Architektur auf der Serverseite eingefugt - Pre-Pro- 
cessor, Pre-Compressor and Post-Compressor. Der Pre-Processor ist fest mit dem Application- Server verbunden, Pre- 
50 und Post-Compressor sind vom Application-Server unabhangig. 

[0060] Die drei SSC-Komponenten klinken sich in den Prozess der Erstellung bzw. der Ubertragung einer dynami- 
schen Webseite ein. Sie werten jeden Block einer bereits generierten Seite aus, prufen, ob der Block statisch oder dyna- 
misch ist bzw, die Daten komprimiert oder unkomprimiert ubertragen werden sollen, und formatieren die Daten am Ende 
nach den GZip-Konventionen, 

55 [0061] Pre-Processor, Pre-Compressor und Post-Compressor sind die SSC-Komponenten, die in die serverseitige Ar- 
chitektur eingefugt werden. Die Anordnung der SSC-Komponenten lasst sich durch den logischen Datenflufi vom Gene- 
rieren einer dynamischen Webseite verdeutlichen. 

[0062] Die Grafik gemaB Fig, 5 zeigt den logischen DatenfluB ohne die SSC-Komponenten, 

[0063] Der Webserver fordert den Application-Server auf, eine dynamische Webseite zu generieren. Der Parser analy- 
60 siert das Template der dynamischen Webseite auf seine statischen und dynamischen Blocke. Der Application-Server fugt 
dann die Tnhalte der Blocke ein und iihergibt anschliel3end die fertige dynamische Webseite dem Webserver, 
[0064] Die Grafik gemaB Fig, 6 verdeutlicht den logischen DatenfluB mit SSC-Komponenten: 
Der Pre-Processor schlieBt sich unmittelbar dem Parser an bzw. verschmilzt mit diesem. Pre- und Post-Compressor - 
ebenfalls eng verkniipft - bearbeiten die Daten nach dem Generieren durch den Application-Server und ubergeben das 
65 S SC-Dokument dem Webserver. Pre- und Post-Compressor konnen - miissen aber nicht auf dem Applic ation-Server lau- 
fen. 

[0065] Den allgemeinen ProzeBablauf beschreibt der folgende Abschnitt. 

[0066] Der Webserver wertet den Request eines Nutzers aus. Hat dieser eine dynamische Webseite angefordert, leitet 
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er die Anfrage an den Application-Server weiter, Der Parser des Application-Server greift auf das abgelegte Template 
dleser Seite zu und analysiert es auf seine statischen und dynamischen Blocke. Gleichzeitig fugt der Pre-Processor an den 
Anfang von jedern Block ein entsprechendes SSC-Tbg ein. Dieses SSC-Tag ist eine SSC-spezifische Markierung, die den 
Block fur SSC eindeutig als statisch bzw, dynamisch kennzeichnet. 

[0067] Danach generiert der Application-Server die Inhalte der Blocke, ohne die eingefugten SSC-Tags zu entfernen. 
Die fertige aber unkomprimierte dynamische Webseite iibergibt er dern Pie-Compressor. Dieser wertet die Webseite an- 
il and der SSC-Tkgs Block fur Block aus. Das bedeutet: 

- Er weist jedem Block eine B lock-ID zu. Diese setzt sich aus der Lange des Blocks und einer errechneten Check- 
summe zusammen. Diese ermoglicht die eindeutige Erkennung des Blocks. 

- Soil der Block kompriroiert werden, priift der Pre-Compressor anhand der Block-ID, ob es ftir diesen Block he- 
re its eine Block-Datei gibt. Die Block-Datei enthalt den Inhalt eines Blocks komprimiert und unkomprimiert, Fin- 
det der Pre-Compressor die Block-Datei, ersetzt der Pre-Compressor den unkomprimierten Block der Webseite 
durch den komprimierten Block aus der Block-Datei, Wenn nicht, komprimiert der Pre-Cornpressor den Block nach 
dem DEFLATE- Verfahren. Zusatzlich erstellt er eine Block-Datei und legt diese fur weitere Verwendungen ab. 

[0068] Parallel zum Pre-Compressor erstellt der Post-Compressor ein SSC-Dokument nach dem GZip Format, in das 
er die vom Pre-Compressor blockweise ubergebenen Inhalte einfugt. Das fertige SSC-Dokument wird iiber den Webser- 
ver zum Browser des Nutzers ubertragen. 

[0069] Fig. 7 stellt die einzelnen Schritte beim Entstehen eines SS C-Dokuments aus dem Template der dynamischen 
Webseite dar, 

[0070] Jeder Block der dynamischen Webseite wird dem DEFLATE- Verfahren unterzogen, D, h„ es komprimiert die 
Blocke zunachst nach festem und nach dynamischem Huffmann-Code und vergleicht die Ergebnisse rnit dem Umfang 
der unkomprimierten Daten. Das Ergebnis mit dembesten Komprbnierungsfaktor wird verwendet. Wird durch das Kom- 
primieren keine Verringerung des Datenumfangs erreicht, verarbeitet das DEFLATE- Verfahren die Daten unkompri- 
miert 

[0071] Das DEFLATE- Verfahren fugt jedem Block einen Header hinzu, deren Aufbau sich je nach verwendeten Daten 
unterscheidet. Die Header sind nachfolgend beschrieben. Der Endblock ist eine Besonderheit von SSC zum Kennzeich- 
nen des letzten Blocks. 

[0072] Das DEFLATE- Verfahren ist eine Kombination des LZ77 (Lempel-Ziv) Algorithmus und dem Kodieren nach 
Huffmann. Es ist in der Spezifikation RFC 1951 "DEFLATE Compressed Data Format Specification version L3" von Pe- 
ter Deutsch beschrieben und definierL 

[0073] Von dem Header eines komprimierten Blocks sind die ersten drei Bits des ersten Byte wie folgt definiert: 













BP^PE 


B FINAL 



10 



15 



20 



25 



30 



35 



Bit 7 6 5 4 3 

[0074] Die Bits bedeuten im einzelnen: 



Bit 


SSC- 
Wert 


Beschreibung 


0 

(B FINAL) 


0 


Flag, das nur beim letzten Block des SSC-Dokuments 
gesetzt wird. 


1-2 

(BTYPE) 


00 
01 
oder 

10 


Spezifiziertdie nachfolgenden Daten: 
Unkomprimierte Daten 

Komprimierte Daten mit festen Huffmann-Code 
Komprimierte Daten mit dynamischen Huffmann-Code 
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Ersten Bits der komprimierten Daten 



40 



45 



50 



[0075] Bei unkomprimierten Datenblocken sind die ersten funf Bytes definiert. Die ersten drei Bits von Byte 1 kenn- 
zeichnen einen Block als unkomprimiert. Daten bleiben unkomprimiert, wenn dies entsprechend konfiguriert wurde und/ 
oder wenn die Ergebnisse der zwei mOglichen Kompressions verfahren (fester und dynamischer Hufiftnann-Code) zu kei- 55 
ner Reduzierung des Datenumfangs fuhrL Der Header setzt sich folgendermafien zusammen: 

Byte 



BTYPE 



Bit 7 6 5 4 3 2 

[0076] Die Bits von Byte 1 bedeuten im einzelnen: 



BFINAL 



LEN 



NLEN 



60 



65 
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Bit 


SSC- 
Wert 


Beschreibung 


0 

(BFINAL) 


0 


Flag, das nur beim letzten Block des SSC-Dokuments 
gesetzt wird. 


1-2 

(BTYPE) 


00 


Bitfolge fur unkomprimierte Daten 


3-7 


0 


Bits zum Auffullen des 1 . Bytes 



[0077] Bytes 2 und 3 beschreiben den Wert fiir die Lange des unkomprimierten Blocks, Bytes 4 und 5 beschreiben den 
Wert fur die Lange des unkomprimierten Blocks minus 1. 

[0078] Fur den letzten Block innerhalb eines SSC-Dokuments muB nach der DEFLATE-Spezifikation das erste Bit 
15 (der BHNAL-Flag) auf 1 gesetzt sein. 

[0079] Wahrend der blockweisen Bearbeitung der Daten ist es fur SSC nicht moglich, automatisch den letzten Block 
zu erkennen, Daher ist das BFINAL-Flag der Datenblocke immer 0, SSC fugt am End© einen zusatzlichen Block, den 
Endblock, ein und setzt das BFINAL-Flag auf 1. Dieser Endblock enthalt keine Daten, 

[0080] Der Pre-Processor ist eng mit dern Parser auf dem Application-Server verkniipft und muB daher auch auf die- 
20 sem laufen. 

[0081] Er markiert als ersten Schritt von SSC jeden Block einer dynamischen Webseite mit einem SSC-spezifischen 
Tag. Diese Tags sind Voraussetzung fur den weiteren SSC-Prozess, Der Pre-Processor kann nur templatebasierte dyna- 
mischen Webseaten bearbeiten. 

[0082] Die SSC-spezifischen Tags dienen dem Erkennen der Blocken einer dynamischen Webseite und dem Kenn- 
25 zeichnen dieser als statisch oder dynamisch. Der Pre-Processor fiigt sie an erste Stelle eines Blocks ein. 

[0083] Die zwei SSC-spezifischen Tags (statisch und dynamisch) entsprechen von ihrer Syntax her einem HTML 
Kommentar. Daraus ergibt sich der Vorteil, da!3 diese Tags als seiche vom Application-Server erkannt aber nicht darge- 
stellt werden. Beisplele fur SSC-spezifische Tags sind: 

30 - statisch: <[— /@— > 

- dynamisch: <!— \@/— > 

[0084] Mit dem Abruf einer templatebasierten dynamischen Webseite greift der Parser des Application-Server auf das 
abgelegte Template zu, Der Parser analysiert das Tfemplate Block fur Block auf deren Charakter (statisch oder dyna- 
35 misch). Gleichzeitig fugt der Pre-Processor das entsprechende statische oder dynamische SSC-spezifische Tag an den 
Beginn des Blocks ein. Durch diesen parallelen Ablauf bleibt die benotigte zusatzliche Rechenlei stung gering. 
[0085] Fig* 8 zeigt beispielhaft das Einfugen der SSC-spezifischen Tags, <? ist das PHP-Anfangstag und ?> das Endtag 
fur den dynamischen Block. 

[0086] Das so analysierte und markierte Template wird anschlieBend durch den Application-Server generiert. Die da- 
40 nach vollstandige unkomprimierte dynamische Webseite mit den eingefugten SSC-spezifischen Tags ubermmmt der Pre- 
Compressor. 

[0087] Der Pre-Compressor setzt eine mit SSC-spezifischen Tags vorbereitete dynamische Webseite voraus. Er iiber- 
nimmt diese mit generiertem Inhalt vom Application-Server. 
[0088] Er uberpruft fur j eden B lock dieser Webseite : 

45 

- den Blocktyp (anhand des SSC-spezifischen Tag), 

- ob der Block komprimiert werden soli bzw. ob fiir diesen Block bereits eine Block-Datei erstellt und abgelegt 
wurde. 

50 [0089] Zu komprimierende Blocke bearbeitet der Pre-Compressor nach dem DEFLATE- Verf ahre n und ubergibt sie 
dem Post-Compressor. Blocke, die unkomprimiert bleiben, ubergibt er sofort dem Post-Compressor. 
[0090] Der Pre-Compres sor ist zusammen mit dem Post-Compressor unabhangig vom Application-Server. D . h. , beide 
konnen auch auf anderen Servereinheiten, z, B, dem Webserver, integriert sein, 

[0091] Der Pre-Compressor weist jedem zu komprimierendem Block eine eindeutige Block-ID zu, Diese Block-ID be- 
55 steht aus zwei Bestandteilen: der CRC-32 Prufsumme und der Lange des unkomprimierten Blocks: 
Block-ID = <CRC-32><Lange des Blocks> 

[0092] Das Kreuzprodukt der CRC-32 Prufsumme und der Lange des unkomprimierten Blocks ergibt eine Block-ID, 
mit der sich ein Block eindeutig bestimmen laBt und damit Vbrwechslungen mit hoher Wahrscheinlichkeit ausschlieBt. 
[0093] Fiir jeden Block einer dynamischen Webseite, der komprimiert werden soil, erstellt der Pre-Compressor eine 
60 Block-Datei. Diese Block-Datei ist in einem bestimmten Verzeichnis abgelegt (gecached) und besteht aus dem Block in 
unkomprimierter und in nach dem DEFLATE- Verf ahren komprimierter Form. Der Name der Block-Datei wird von der 
Block-ED gepragt, die Endung kann dem Charakter des Blocks entsprechen. Beispiel fur eine Kennung ist: SSC-cache- 
<Lange>-<CRC-32>.static 

[0094] Fig. 9 zeigt den Aufbau einer Block-Datei. 
65 [0095] Der Pre-Compressor bearbeitet die vom Application- Server iibernommene dynamische Webseite blockweise. 
Dabei priift er als erstes, ob der Block komprimiert abgelegt werden soli oder nicht. Wenn nicht iibernimmt der Post- 
Compressor den unkomprimierten Inh alt des Blocks, Ist eine Komprimierung gefordert, errechnet der Pre-Compressor 
fur den Block die Block-ID und pruft mit dieser Block-ID, ob fur diesen Block bereits eine Block-Datei erstellt und ab- 



6 



DE 101 46 356 A 1 



gelegt ist. Entsprechend dem Ergebnis ergeben sich 2 Fallsiruationen, 

Fall 1 (Fig. 10): Der Pre-Cornpressor findet die entsprechende Block-Datei. Der Post-Compressor ubernimmt den kom- 
primierten Block aus dieser Block-Datei. 

Fall 2 (Fig, 11): Es gibt noch keine entsprechende Block-Datei, Der Pre-Compressor komprimiert den Block nach dem 
DEFLATE- Verfahren und ubergibt diesen den Post-Compressor. Zusatzlich erstellt er eine Block-Datei und legt diese ab, 5 
[0096] Der Post-Compressor ubernirnmt vom Pre-Compressor die komprimierten bzw. unkomprimierten Blocke und 
erstellt aus diesen ein SSC-Dokument. 

[0097] Der Post-Compressor ist zusammen mit dem Pre-Compiessor unabhangig vom Application-Server. D, h„ beide 
konnen auch in anderen Servereinheiten, z, B, dem Webserver, integriert sein, 

[0098] Das SSC-Dokument setzt sich, wie aus Fig, 12 erkennbar, aus einem Header, den einzelnen Datenblocken und 10 
einem Trailer zusammen. Dieser Aufbau entspricht dem GZip-Format, der in der Spezifikation RFC 1952 "GZEP file for- 
mat specification version 43" von Peter Deutsch definiert und beschrieben ist. 
[0099] Der Aufbau des Header (Kopf) vom SSC-Dokument setzt sich folgendermaBen zusammen: 



1 


2 


3 


4 


5 


6 7 


6 


9 


10 


ID1 


ID2 


CM 


FLG 


MTIME 


XFL 


OS 



[0100] Die einzelnen Bytes bedeuten: 20 



Byte 


SSC-Wert 


Beschreibung 


1 




ID1 - erstes Byte zur Identifizierung des gzib-Formats 


2 




ID2 - zweites Byte zur Identifizierung des gzib-Formats 


3 


8 


CM - Byte bestimmt Komprimierunpsmethode (deflate) 


4 


0 


FLG - Einstellungen 


5-8 


0 


MIME - Zeit der Komprimierung der Datei fur SSC alle 4 
Bytes 0 kein Zeitstempel 


9 


0 


XFL - Flag fur spezifische Komprimierungsmethoden 


10 


0 


OS - Byte zur Identifizierung des Betriebssytems 



[0101] Das SSC-Dokument endet mit einem 8 Byte groBern Trailer (Anhang). Diese Bytes baben folgende Bedeutung: 



Byte 


Beschreibung 


1 -4 


CRC32 - Checksumme 


5-8 


ISIZE - GroBe des unkomprimierten Datenblocks 



40 

[0102] Der Post-Compressor erstellt parallel zur Auswertung der dynamischen Webseite durch den Pre-Compressor 
ein neues Dokument nach dem GZip-Format, Dabei bildet der Post- Compressor zunachst den GZip- Header: Anschlie- 
Bend reiht er unmittelbar mit der Ubergabe der Blocke durch den Pre-Compressor diese Block fur Block in das Doku- 
ment ein. 

[0103] Unkomprimierte Blocke, die der Pre-Compressor obne Bearbeitung weiterleitet, kennzeicbnet der Post-Corn- 45 
pressor durcb einen Header entsprecbend dem DEFLATE^Format, 

[0104] Sind alle Blocke der dynamischen Webseite abgearbeitet, erganzt der Post-Compressor einen zusatzlichen End- 
Block, der keine Daten enthalt. Das BFINAL-Hag (BFINAL = 1) im Header des End-Blocks kennzeichnet das Ende der 
Datenblocke, 

[0105] Als letzten Schritt errechnet der Post-Compressor die Checksumme und die Grofte des unkomprimierten Daten- 50 
blocks fiir den Trailer. 

[0106] Das fertige SSC-Dokument ubergibt der Post-Compressor dem Webserver, der dieses zum Nutzer weiterleitet. 
[0107] In der beiliegenden Fig. 1 3 ist ein Ausfuhrungsbeispiel der erfindungsgemaBen Datenverarbeitungseinrichtung 
im Prinzip gezeigt. Hierbei ist ein Webserver 10 mit einem Application-Server 11 verbunden, auf welchem ein Parser 12 
lauft. Der Parser 12 ist eng mit einem Pre-Processor verbunden, lauft also ebenfalls auf dem Application-Server 11. Der 55 
Pre-Processor (mit dem Parser) bearbeitet die dynamischen, templatebasierten Webseiten. 

[0108] Es ist ein Pre-Compressor 14 vorgesehen, der zusammen mit einem Post- Compressor 15 vorzugsweise unab- 
hangig vom Application-Server ist, also mit dem Pre-Compressor 14 z, B. im Webserver integriert sein kann. Schliefilich 
ist ein Blockspeicher 13 vorgesehen, der mit dem Pre-Compressor 14 verbunden ist, so daB der Pre-Compressor 14 den 
Blockspeicher 13 auf dort schon gespeicherte komprimierte statische Blocke untersuchen bzw. statische Blocke nach 60 
dem Komprirnieren dort ablegen kann. 



Bezugszeichenliste 

10 Webserver 65 

11 Application-Server 

12 Parser 

13 Blockspeicher 
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14 Pre-Compressor 

15 Post-Compressor 

Patentanspriiche 

5 

L Verfahren zum Komprimieren von dynamischen Webseiten, insbesondere zum Komprimieren von Webseiten, 
die ndndestens einen statischen Block und wenigstens einen dynamischen, insbesondere durch Abruf von einem 
Nutzer veranderlichen Block aufweisen, die auf einem Webserver und einem Application- Server vorgehalten oder 
generiert werden, umfassend die Schritte: 
10 - Aufhehmen eines Datensatzes, umfassend mindestens einen statischen und einen dynamischen Block; 

- Feststellen jeweils einer Identitat aller im Datensatz vorhandenen statischen Blocke; 

- Feststellen, ob statische Blocke mit derselben Identitat in einem Blockspeicher schon als komprimierte 
Blocke gespeichert sind und 

- entweder Ersetzen des im Datensatz vorhandenen statischen Blocks durch einen komprimierten Block 
15 dann, wenn der statische Block im Blockspeicher als komprimierter Block gespeichert ist; 

- oder Komprimieren des statischen Blocks und Abspeichern im Blockspeicher als komprimierter Block 
dann, wenn der statische Block noch nicht im Blockspeicher gespeichert ist und Ersetzen des statischen 
Blocks durch den komprimierten Block; 

- Absenden eines Sende-Datensatzes, bei welchem die statischen Blocke durch komprimierte Blocke ersetzt 
20 sind und der die dynamischen Blocke enthalt. 

2, Verfahren nach Anspruch 1, wobei die Identitat eines statischen Blocks anhand einer, aus ihm selbst gewonnenen 
Kennung (Fingerprint) festgestellt wird, 

3. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 2, wobei die aus der Identi- 
tat gewonnene Kennung jedem komprimierten Block zugehorig im Blockspeicher gespeichert und beim Feststellen 

25 der Identitat zum Vergleich mit den Identitaten der statischen Blocke im Datensatz verwendet wird. 

4, Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 2 oder 3, da- 
durch gekennzeichnet, da!3 die Kennung eine Prufsumme iiber den statischen Block umfaBt. 

5. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 4, dadurch gekennzeichnet, 
daB die Kennung die Lange des statischen Blocks umraBt, 

30 6, Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB zusatzlich zu jedem kom- 

primierten Block der dazugehorige statische Block abgespeichert wird. 

7. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Daten nach dem DE- 
FLATE^ Verfahren komprimiert werden. 

8. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die dynamischen Blocke im 
35 wesentlichen unverandert, insbesondere unkomprirniert im Sende-Datensatz enthalten sind. 

9. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 1 bis 7, dadurch 
gekennzeichnet, daB mindestens ein dynamischer Block komprimiert und als komprimierter dynamischer Block in 
den Sende-Datensatz eingefugt wird. 

10. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 9, dadurch gekennzeich- 
40 net, daB abhangig von einer momentanen Arbeksbelastung eines Servers, insbesondere des Webservers, dynami- 

sche Blocke komprimiert oder unkomprirniert abgesendet werden, 

11. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB jedem letzten Block eines 
Datensatzes ein Endblock zur Bezeichnung des Endes des Datensatzes hinzugefugt wird. 

12. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB jeder Block des Datensat- 
45 zes ein Tag zur Kennzeichnung als dynamischer oder als statischer Block insbesondere an erster S telle hinzugefugt 

wird. 

13. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 12, dadurch gekennzeich- 
net, daft die Tags als HTML-Kommentar ausgebildet sind. 

14. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 12 oder 13, da- 
50 durch gekennzeichnet, daB die Tags von einem Parser eingefugt werden, der auf einem Application-Server lauft und 

auf abgelegte Templates zugreift, die er Block fur Block analysiert und denen er die T&gs hinzufiigt. 

15. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 14, dadurch gekennzeich- 
net, daB die mit den Tags markierte unkomprimierte Webseite einem Prekompressor zugefuhrt wind, der entspre- 
chend markierte Blocke komprimiert, die zusammen mit unkomprimierten Blocken einem Postkompressor iiberge- 

55 ben werden. 

16. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 15, dadurch gekennzeich- 
net, daB der Postkompressor schritthaltend zur Datenbearbeitung durch den Prekompressor ein neues Dokument, 
vorzugsweise nach dem Gzip-Format erstellt, 

17. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 16, dadurch gekennzeich- 
60 net, daB der Postkompressor nach Bildung eines Gzip-Headers die vom Prekompressor iibergebenen Blocke unmit- 

telbar mit der tJbergabe in das neue Dokument einreiht. 

18. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach Anspruch 17, dadurch gekennzeich- 
net, daB der Postkompressor unkomprimierte Blocke durch einen Header, vorzugsweise einen Header entsprechend 
dem DEFLATE-Format kennzeichnet. 

65 19. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 15 bis 18, da- 

durch gekennzeichnet, daB der Postkompressor einen zusatzlichen END-Block erstellt und zur Kennzeichnung ei- 
nes Endes der Datenblocke dem neuen Dokument hinzufiigt. 

20. Verfahren nach einem der vorhergehenden Anspriiche, insbesondere nach einem der Anspriiche 16 bis 19, da- 
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durch gekennzeichnet, daB der Postkompressor eine Checksutnine, insbesondere eine CR-3 2-Priif summe und die 
GroBe des unkomprimierten neuen Dokuments fur einen Trailer errechnet 

21. Verfahren nach einem der vorhcrgehenden Anspruche, insbesondere nach Anspruch 9, dadurch gekennzeich- 
net, daB dynamische Blocke in Abhangigkeit 

von rnindestens einem ihnen innewohnenden Merkmal, insbesondere in Abhangigkeit von ihrer GroBe vorkompri- 5 
miert gespeichert werdem 

22. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB 

eine Kompression von Datenblocken nur dann voigenommen wird, wenn diese eine voieinstellbare MindestgroBe 
uberschreiten. 

23. Datenverarbeitungseinrichtung zum Komprimieren von dynarnischen Webseiten, insbesondere zum Kornpri- 10 
mieren von dynarnischen Webseiten, die mindestens einen statischen Block und mindestens einen dynarnischen 
Block aufweisen, umfassend 

einen Webserver (10) und einen Application-Server (11), gekennzeichnet durch einen Prekornpressor, der so ausge- 
bildet ist, daJ3 bei Aufforderung durch den Webserver (10) an den Application-Server (11) eine dynamische Web- 
seite zu generieren, der Prekornpressor eine unkomprimierte Webseite in folgenden Schritten bearbeite: 15 

- Feststellen jeweils einer Identitat aller im Datensatz vorhandenen statischen Blocke; 

- Feststellen, ob statische Blocke mit derselben Identitat in einem Blockspeicher schon als komprimierte 
Blocke gespeichert sind und 

- entweder Ersetzen des im Datensatz vorhandenen statischen Blocks durch einen komprimierten Block 
dann, wenn der statische Block im Blockspeicher als komprimierter Block gespeichert ist; 20 

- oder Komprimieren des statischen Blocks und Abspeichem im Blockspeicher als komprimierter Block 
dann, wenn der statische Block noch nicht im Blockspeicher gespeichert ist und Ersetzen des statischen 
Blocks durch den komprimierten Block; 

- Absenden eines Sende-Datensatzes, bei welchem die statischen Blocke durch komprimierte Blocke ersetzt 
sind und der die dynarnischen Blocke enthalt, 25 

24. Datenverarbeitungseinrichtung nach Anspruch 23, dadurch gekennzeichnet, daB der Parser (12) so ausgebildet 
ist, daB die aus der Identitat gewonnene Kennung jedem komprimierten Block zugehorig im Blockspeicher gespei- 
chert und beim Feststellen der Identitat zum Vergleich mit den Identitaten der statischen Blocke im Datensatz ver- 
wendet wird. 

25. Datenverarbeitungseinrichtung nach einem der Anspruche 23 oder 24, dadurch gekennzeichnet, daB der Web- 30 
server (10) derart ausgebildet ist, daB abhangig von seiner momentanen Arbeitsbelastung dynamische Blocke kom- 
primiert oder unkomprimiert abgesendet werden. 

26. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 25, dadurch gekennzeichnet, daB der Parser 
(12) derart ausgebildet ist, daB Tags von ihm eingefugt werden, wobei der Parser (12) auf dem Application-Server 
(11) lauft und auf abgelegte Templates zugreift, die er Block fur Block analysiert und denen er die Tags tdnzufugt. 35 

27. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 26, dadurch gekennzeichnet, daB ein Prekorn- 
pressor (14) vorgesehen ist, welchem die mit den Tags markierten unkomprirrderten Webseiten zugefuhrt werden 
und der zu Komprimierung entsprechend markierter Blocke ausgebildet ist, und daB ein Postkompressor (15) vor- 
gesehen ist, dem die komprimierten Blocke zusammen mit unkomprimierten Blocke vom Prekornpressor (14) iiber- 
geben werden. 40 

28. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 27, dadurch gekennzeichnet, daB der Post- 
kompressor (15) schritthaltend zurDatenverarbeitung durch den Prekornpressor (14) und zurErstellung eines neuen 
Dokuments vorzugsweise nach dem Gzip-Format ausgebildet ist. 

29. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 28, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Bildung eines Gzip- Headers und zur unmittelbaren Einreihung der vom Prekornpressor (14) 45 
ubergebenen Blocke rnit der Ubergabe in das neue Dokument ausgebildet ist. 

30. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 29, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Kennzeichnung unkomprimierter Blocke durch einen Header, vorzugsweise einen Header ent- 
sprechend dem DEFLATE-Forrnat ausgebildet ist. 

31. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 30, dadurch gekennzeichnet, daJ3 der Post- 50 
kompressor (15) zurErstellung eines zusatzlichen END-Blocks und zur Hinzufugung des END-B locks zur Kenn- 
zeichnung eines Endes der Datenblocke zum neuen Dokument ausgebildet ist. 

32. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 31, dadurch gekennzeichnet, daB der Post- 
kompressor (15) zur Bildung einer Checksumme und Herleitung der GroBe des unkomprimierten neuen Dokuments 
und zur Erstellung eines Trailers ausgebildet ist. 55 

33. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 32, dadurch gekennzeichnet, daB der Prekorn- 
pressor derart ausgebildet ist, daB dynamische Blocke in Abhangigkeit von mindestens einem ihnen innewohnen- 
den Merkmal, insbesondere in Abhangigkeit von ihrer GroBe vorkompri miert gespeichert werden, 

34. Datenverarbeitungseinrichtung nach einem der Anspruche 23 bis 33, dadurch gekennzeichnet, daB der Prekorn- 
pressor derart ausgebildet ist, daB eine Kompression von Datenblocken nur dann vorgenommen wird, wenn diese 60 
eine voreinstellbare MindestgroBe iiberschreiten. 
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